home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14736 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.2 KB
  1. Path: in2.uu.net!csnews!boulder!usenet
  2. From: Edmond <underwoe@Colorado.Edu>
  3. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.win32
  4. Subject: Re: VC++ 4.0 memory allocation slower than in 2.x!!!
  5. Date: Mon, 01 Apr 1996 15:04:43 -0700
  6. Organization: CNS
  7. Message-ID: <316052FB.2014@Colorado.Edu>
  8. References: <alanDozpsy.Kn6@netcom.com> <315C4DA0.30C@Bentley.com> <316049E7.739D@sdt.com>
  9. NNTP-Posting-Host: samiam.colorado.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=iso-8859-1
  12. Content-Transfer-Encoding: quoted-printable
  13. NNTP-Posting-User: underwoe
  14. X-Mailer: Mozilla 2.0 (X11; I; SunOS 5.4 sun4m)
  15.  
  16. Larry Baker wrote:
  17. > =
  18.  
  19.  
  20. > - VirtualAlloc operates directly on the virtual memory tables; hence,
  21. >   it allocates memory pages at a time, where you specify the address
  22. >   range to allocate, and has options for locking them in memory, etc.
  23. >   But explicit management of the memory provided (suballocation) must
  24. >   be done manually.  To those who can check: is the 2.0 *alloc thread-
  25. >   safe?
  26. > =
  27.  
  28. > - GlobalAlloc operates on 'the heap.'  It appears to be a legacy
  29. >   interface to the old Win16/Win32s interface(s).  There is no mention
  30. >   of thread-safeness.
  31. > =
  32.  
  33.  
  34. This call is outdated and shouldn't be used anymore.  I imagine that the
  35. kernel turns it into HeapAlloc (or the runtime library).  =
  36.  
  37.  
  38. > - HeapAlloc, by default, performs mutual exclusion on its heap
  39. >   object argument. This incurrs an unnecessary performance penalty
  40. >   if you're a single-threaded app and can be avoided if you allocate
  41. >   per-thread heaps if your a multi-threaded app.  Otherwise, it's
  42. >   necessary, either at the OS or at the runtime level.  See the excerpt
  43. >   from my Win32 Online Help, below.
  44. > =
  45.  
  46. > - VirtualAlloc appears to be the low-level interface to the virtual
  47. >   memory subsystem. GlobalAlloc appears to be a general heap manager,
  48. >   and does not differentiate between the old local or global heaps.
  49. >   HeapAlloc appears to be a complete generalization of heap management,
  50. >   accounting for thread-safeness at the OS level.
  51. > =
  52.  
  53. > - This sort of thing can't help but bias benchmarks, as evidenced
  54. >   by last months' Byte Magazine on the subject.  They discovered a
  55. >   similar performance sensitivity to malloc: sometimes (at least, with
  56. >   MS 4.x) it returns byte-aligned allocations, rather than word
  57. >   aligned.  This causes roughly a 50% (20%?) performance penalty on the
  58. >   Pentium for misaligned 32-bit or greater reads, as the hardware has
  59. >   to do some monkey business for things like floats, doubles, ints...
  60. > =
  61.  
  62.  
  63. This is their (Byte's) own blunder that they made a bigger deal of than
  64. it should have been.  Most compilers stick with MS's routine for memory
  65. allocation so I'd imagine that all of them show this behavior.
  66.  
  67. > - It would be useful if someone with 4.x could check their online
  68. >   reference materials to see if they can illuminate the subject further.
  69. > =
  70.  
  71. > From the Win32 Online Help accompnaying my Borland C++ v4.52:
  72. > =
  73.  
  74.  
  75. Check out Jeffrey Richter's Advanced Windows programming.  I think it's
  76. somewhat better than the old, outdated, Borland guide to poor Win32
  77. programming.
  78.  
  79.  
  80. > =B7       The process has only one thread.
  81. > =B7       The process has multiple threads, but only one thread calls the=
  82.  
  83. >         heap functions for a specific heap.
  84. > =B7       The process has multiple threads, and the application provides
  85. >         its own mechanism for mutual exclusion to a specific heap.
  86. > =
  87.  
  88.  
  89. Other than it's very good exception handling, I don't see any reason to
  90. use HeapAlloc()'s over VirtualAlloc()'s (BTW:  HeapAlloc supposedly
  91. defaults to VirtualAlloc when you have run out of physical memory).  Why
  92. would different threads be allocating/removing the same block of memory
  93. anyway.  That would pose synchronization problems that would be sure to
  94. cost your application a lot of unnecessary time wasting.  I would simply
  95. use the VirtualAlloc routine (with some inherent calls to _heapmin()
  96. here and there) giving the job of allocating and deallocating to the
  97. main application thread and using the HeapDestroy(GetProcessHeap()...)
  98. upon program removal.  I think one would have safer, faster, memory
  99. allocation routines this way.  =
  100.  
  101.  
  102. -- =
  103.  
  104. Edmond Underwood
  105. email:  underwoe@Colorado.Edu
  106. Bench32 for Windows NT and Windows 95
  107. http://www.rmii.com/~underwoe/bench32.html
  108.